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TITLE 



SYSTEM FOR CAPTURING TRADE INFORMATION 

BACKGROUND OF THE INVENTION 
Field of the Invention 

The present invention relates to an automated 
trade capture system having a client interface. 
Related Background Art 



executing trades among brokers, market managers, 
individual traders and other financial entities. See, 
for example, U.S. Patents Nos . 4,674,044, 5,950,176, 
and 5,963,92 3. In addition, a few large brokerages 
have developed on-line trading systems for individual 
traders. These systems, however, do not provide for 
middle office and back office processing, such as by an 
investment bank acting either as a principal or a 



Various automated systems already exist for 
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clearing agent, of a trade previously executed between 
two parties . 

Such middle and back office processing has 
been performed internally by the investment bank of 
5 Lehman Brothers, in an in-house version of its 

SMARTTICKET™ automated trade capture system. In this 
system, executed trade information was captured by 
Lehman Brothers personnel from written documents sent 
to them from external clients. The captured trade 

10 information was then sent through a workflow process 
consisting of trader and middle office trade 
authorizations, as well as back office processing. 

However, while being automated, this in-house 
system did not permit any trade capture to be performed 

15 by the clients themselves. Further, the trades were 
mostly limited to derivatives . 

A client-assessable trade capture system is 
desirable, however, because it would provide clients 
with a single trade capture platform, in which products 

2 0 besides derivatives, such as cash and futures trades, 
may be handled, which in turn provides the investment 
house a competitive advantage. A client-assessable 
trade capture system would also provide the clients 
with links to the internal risk, margin and 



counterparty services of the investment bank, access to 
historical trade activity, as well as trade validation 
and conf irmation. 

SUMMARY OF THE INVENTION 
To overcome the above-described and other 
limitations in the art, the present invention relates 
to a system that preferably provides an efficient and 
streamlined system , for capturing trades that can be 
operated by the client at its site. 

In one aspect of the present invention, a 
trade capture system is provided that includes a first 
computer having an interface for capturing executed 
trade data, a second computer for accepting the 
captured trade data and performing middle and back 
office processing on the same, and a communication 
channel for communicating the captured trade data 
between the first and second computers. Preferably, 
the first computer is a client computer, the second 
computer is an investment bank computer, and the 
communication channel is the Internet, wherein the 
client computer's interface is a browser. 

In another aspect of the present invention, a 
trade capture system is provided which includes a first 
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computer having an interface for transmitting 
electronic trade tickets, a second computer for 
receiving the electronic trade tickets and performing 
middle and back office processing on the same, and a 
5 communication channel for communicating the electronic 
trade tickets between the first and second computers. 

These and other aspects of the present 
invention are described in more detail below. 

10 BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 is a state diagram showing the states 
and actions ("workflow") of the present invention. 

Fig. 2 is a screen shot of a graphical user 
interface of the present invention relating to a new 
15 deal. 

Fig. 3 is a screen shot of a graphical user 
interface of the present invention relating to a swap 
accelerator. 

Fig. 4 is a screen shot of a graphical user 
20 interface of the present invention relating to a 
generic swap . 

Fig. 5 is a screen shot of a graphical user 
interface of the present invention relating to a swap 
leg of Party A. 
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Fig. 6 is a screen shot of a graphical user 
interface of the present invention relating to a swap 
leg of Party B. 

Fig. 7 is a screen shot of a graphical user 
5 interface of the present invention relating to a trade 
authorization. 

Fig. 8 is a screen shot of a graphical user 
interface of the present invention relating to risk 

Q 

*J management details. 

10 Fig. 9 is a screen shot of a graphical user 

rg interface of the present invention relating to a deal 

s filter. 

O 

H Fig. 10 is a screen shot of a graphical user . 

interface of the present invention relating to a deal 

s a 

^ 15 workflow history. 

Fig. 11 is a block diagram of the system 
architecture of the present invention. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
20 OVERVIEW 

The following describes as a preferred 
embodiment of the present invention Lehman Brothers' 
SMARTTICKET™ client-based trade capture system that was 
first made publicly available on January 17, 2000. \ 
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However, the following description is not limited to 
that system, and may include additional features not 
present in that system. 

An embodiment of the present invention is 
5 shown in Fig. 11, and includes a client computer 1100, 
a communication channel 1102, and the investment bank's 
middle office and back office processing computer 
system 1104. As shown in that figure, the client 
computer 1100 of the present invention is installed at 

10 the client's site, and is preferably connected to the 
investment back's computer system 1104 through the 
Internet 1106. Of course, other types of well-known 
communication channels 1102 may be employed instead to 
connect and communicate information between the client 

15 computer 1100 and the investment bank's computer system 
1104. 

Executed trades may be entered directly into 
the system's interface 1110 on the client's computer. 
Alternatively, the client may have its own interface 
20 1112 which connects to the system of the present 

invention, and in that case, the trades are entered by 
the client into its own interface, which in turn are 
transmitted through the Internet or other communication 
channel to the system 1104. 
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Additionally, the system 1104 may receive 
from the client's computer 1100, via the electronic 
trade ticket interface 1114, over the Internet or 
communication channel, trade tickets which contain the 
5 executed trade data. This eliminates/ or at least 

reduces, the need for the client to key trade data into 
its interface. The investment back system 1104 accepts 
those trade tickets electronically, preferably using 
XML technology, on a real-time basis. 

10 Because it is desirable for the system 1104 

to support as many clients as possible, it supports a 
wide variety of trades besides traditional derivatives. 
Accordingly, the system 1104 is described below with 
respect to trades, such as swaps, swaptions, caps, 

15 floors, FX, and cash, related to derivatives, futures 
and cash products, including both U.S. and non-U. S. 
products. However, it will be appreciated that the 
system may be extended to accept executed trades of 
other financial products. As will be described in more 

20 detail below, to give clients more flexibility to trade 
in both derivatives and cash products, templates exits 
for both the derivatives and cash business. For 
example, these templates allow for the capture of 
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outright bond trades, financing trades and futures and 
options trades . 

Separate entities within the investment bank 
system 1104 are set up according to product type, 
5 mainly for security and safekeeping purposes . For 

example, for U.S. products and for global derviatives, 
separate entities are set up for each client in the 
respective internal system. For non-U. S. cash 
products, a separate entity is also used to segregate 

10 the client's financing trades to properly keep them 
(i.e., for client reporting and balance sheet 
purposes). In addition, for U.S. cash products, a 
unique bank depository may be set up for each client, 
while for non-U. S. cash products, a investment bank or 

15 bank/depository account may be used. Separating each 
client's data provides a security layer to the system, 
because a client can view and access only its own 
trades and no others. Further, a profile may be set up 
for each client, in which the client is restricted to 

20 access only certain products (e.g., swaps), allowing 

the client to trade in only those products for which it 
signed up for. 

In addition, to support hedge funds clients, 
the client's interface 1104 supports a client 
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allocation function. This function allows the client 
to enter a single trade and then allocate that trade 
into multiple trades (i.e., multiple funds) based on 
the allocation breakdown specified by the client. This 
5 function significantly speeds up the trade capture 
process for those clients. 

Further, the client's interface may includes 
a trade blotter screen developed for that client's 

r~i 

business. This blotter gives the client the ability to 

m 

_z= 10 sell of its trades, across different product types, on 

m one integrated screen. Data may be viewed for the 

5 current day of any date range entered. 

Once the trade data have been captured by the 
J? system 1104, the trade data may be routed to the 

^~ 15 appropriate internal system of the investment house, 

based on the product. The investment bank may then 
verbally confirm, on trade date, the trade that the 
client has executed with its street counter-party. 
This trade may be confirmed with the investment bank 
20 acting as either a principal or as a clearing agent. 
Once the trades are confirmed, they may be settled by 
the investment bank, for which the investment bank 
moves either the cash or securities based on the 
client's instructions. The client may then be notified 
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of the trade settlement by the investment bank, for 
example , by its computer system, through the 
communication channel, to the client's computer. 

5 DEAL CAPTURE 

This section describes a preferred embodiment of 
capturing deal information in the system of the present 
invention. Deal capture begins with specification of 

O 

M3 the product type to be captured. This allows the 

10 system to provide the user with a template for 
^ capturing the specific information needed for that 

fu 

deal. Field entry is simplified, because values for as 
Mi many fields as possible are defaulted based on product 

SI type. As fields are populated, other fields are 

^ 15 assigned default values based on that information. 

Field entry may then be validated for all fields. 
Files may then be saved and named in preparation of 
moving deals into the system workflow, which is also 
described in detail below. 
20 System menus and toolbars may be configured 

similar to Microsoft applications, with all functions 
available on drop-down menus at the top of the screen. 
Selected functions are available as buttons on the 
system toolbar. The user preferably has access to all 



functions through both mouse and keystroke selection. 
If any function cannot logically be performed by a user 
based on the user profile, deal state, or mode of file 
access, that menu item is made inactive. Inactive menu 
items are stippled (shaded light gray). 

As shown in Fig. 2, new deals are created by 
first selecting a senior product type and a subordinate 
product type, which together define the structure and 
data fields needed to capture that deal. 

For example: 

Senior Product Type = Interest Rate Swap 
Subordinate Product Type = Generic Fixed vs . 

Floating 

A template may then be stored in system for 
each combination of senior and subordinate product 
types. As new deal structures are recognized, new 
product types may be defined, and new templates may be 
created by system users . In addition to the system 
templates created for all users, each user will be able 
to create custom (or "user") templates for individual 
or shared use. The user will be able to choose from 
the lists of system and custom templates to initiate 
deal capture. The client's interface preferably only 
contains the system templates. Figs. 3 and 4 
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respectively show a swap accelerator and a generic swap 
generated by the client using the templates. 

When the first piece of deal information is 
captured, the selected template becomes a "Deal in 
Progress", which is the first valid deal state (102) in 
the system workflow. The Deal in Progress is assigned 
an ID within system that remains with the Deal in 
Progress until it becomes an authorized deal, or is 
deleted* The Deal in Progress belongs exclusively to 
the user creating it until it is explicitly shared with 
other users, called a Deal in Progress Transfer. The 
ticket will remain in the user inbox of the creator 
until it is sent to another user for processing. 

In the system of the present invention, Party 
A may be selected to be the investment bank entity. 
The defaulting investment bank entity is based on user 
preferences and can be changed based on a choice list 
of valid investment bank entities. As for the 
counterparty (Party B), a counterparty browser allows 
the selection of that party directly from an entity 
master database. This ensures that deals are booked 
with valid counterparties . In addition to counterparty 
name, branch, and ID, other information about the 
counterparty stored on the entity master database are 
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viewable. Preferably, none of the information in the 
entity master database is editable from the system of 
the present invention itself, and thus is separately 
edited. In cases where the counterparty has not yet 
5 been set up on the entity master database, the option 
to enter the counterparty as "TBD" (To Be Determined) 
with a free-format name is provided. Replacement of 
the "TBD" counterparty with a counterparty from the 
entity master database may be enforced by preventing 

10 the deal from reaching its final state until the "TBD" 
counterparty issue is resolved. 

System field entry consists of populating the 
selected template with deal information. In most 
cases, fields will have a default value based on the 

15 product type, or the values of other fields. The user 
may override these defaults, however, usually by 
picking from a choice list of values. 

Field values are typically validated 
according to validation rules recorded in the system. 

20 If a field value is determined to be invalid, an error 
message is displayed and the focus will remain on that 
field. Where applicable, fields may be validated in the 
context of the values of other fields on the ticket. 
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The system also includes a field propagation 
engine, which is used to propagate the effects of one 
changed field value on other fields. A change in one 
field may propagate such changes to other fields such 
as making them visible or invisible, changing their 
default values, and determining whether they are 
required or not required. 

Required fields are those fields that must be 
populated given the selected product type, the values 
of other fields that have already been populated, and 
the state of the deal (which states are described in 
detail below) . If a field is required given these 
parameters, the system does not allow the deal to 
transition to the next state. There are no fields 
required for a ticket to exist in the Deal in Progress 
state. All economic data fields are preferably 
required before trader authorization can occur. 

A limited free-format comment field is 
provided on each template to capture information that 
cannot be captured on an existing template. This 
comment field is monitored by the middle office so that 
an appropriate custom template can be constructed. 

System deal legs may be selected, copied, and 
pasted within deals or from one deal to another. The 
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deal the leg is being copied from may be open in Write 
Mode or Read-only Mode, but the deal the leg is being 
pasted onto must typically be open in Write Mode. If a 
deal is open in Write Mode, legs may be selected and 
5 deleted. Legs may also be chosen from a menu of 

available legs to be inserted onto a deal. A display 
of swap legs is shown in Figs. 5 and 6. 

During deal capture, the system periodically 
saves captured deal information to a temporary file to 

10 minimize data loss due to an interruption in network 

service or an unanticipated PC re-boot. The temporary 
save occurs every pre-determined number of minutes 
(e.g., five minutes), and the temporary file is deleted 
when the user explicitly closes the file, which is 

15 known as a "clean close". When logging on to the 

system, the user is advised of any files that were not 
"closed clean" when the user last logged out. The user 
may then be given the option to recover the last 
autosaved version of the file. 

20 A file may be saved as a Deal in Progress or 

as a custom template. If a deal in progress has not 
previously been explicitly saved, the user may be 
prompted to save the file as a Deal in Progress or as a 
custom template. If the file has been previously 
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saved, or if the file is an authorized deal, the 
updated version of the file may be saved in place of 
the old version. Any file may be saved as a Deal in 
Progress. None of the fields on a system or custom 
5 template are required for a file to be saved as a Deal 
in Progress. Any file open in Write Mode or Read-only 
Mode may be saved as a custom template. The resulting 
custom template will be "owned" by the user who created 
it, and will be available only to that user unless 

10 explicitly changed by that user. 

Preferably, system file names consist of the 
originating office, the trade date, the Party A ID, the 
Party B ID, and a user-defined free-format portion. 
This free-format portion is created by the user who 

15 originates the deal, and may be changed only by that 
user unless "ownership" of that deal is explicitly 
changed. 



SYSTEM WORKFLOW 
20 This section describes a preferred embodiment 

of the workflow of the system of the present invention. 
System workflow entails moving a ticket through a 
series of states, each closely associated with a group 
of users that must process the ticket in each state. 
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There are five valid deal states: Deal in Progress 102 , 
(Deal) Pending Trader Authorization 104, (Deal) Pending 
AAA Authorization (105), (Deal) Pending Middle Office 
Processing (106), and Active Deals in Back Office 
5 (107). In the basic workflow, a Deal in Progress is 
created by the client or by a marketer, who populates 
most of the deal information fields and obtains the 
necessary credit and AAA approvals (AAA approvals are 
?H simply an extra level of authorization required for 

1=] 10 certain deals by the investment bank) . The Deal in 

Progress of state 102 is then submitted for trader 
~ authorization, entering the Pending Trader 

N- Authorization state 104. When authorized, the deal 

then moves to the Pending Middle Office Processing 
^ 15 state 106. When this is complete, the ticket is 

authorized to the final state, Active Deals in Back 
Office 107. If the deal is an AAA trade, it must pass 
through the additional state 105 of Pending AAA 
Authorization before reaching the Pending Middle Office 
20 Processing state 106. At any time after the ticket 
becomes an authorized deal, users will be able to 
Attach Proposed Edits to the ticket and re-submit it 
for Trader Authorization. The system workflow also 
handles processing of terminations and assignments. 
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Fig. 1 is a state diagram showing the states 
and actions of the system workflow. Each large circle 
represents one state that the executed trade , or 
"deal", may take while being processed by the system. 
5 The thick, dark arrows represent successful movements 
in which the deal goes forward. The dotted lines 
represent deal deletions or rejections, or a rejection 
by the trader of a proposal from the middle office or 
back office. The dashed lines represent proposals from 
10 the middle office or back office. 

In state 101 "Deal Being Created But Not 
Saved Yet", the client enters into the graphical user 
interface of the system the required trade information, 
as well as other deal-related information, as explained 
15 further below. When all necessary information has been 
entered, the client saves the deal, which brings the 
workflow to state 102, "Deal in Progress". 

In state 102, two actions may occur: the 
client may delete the deal in progress, in which .case 
20 the workflow moves to state 103, "Deal No Longer 

Exists". At that point, the deal dies and no further 
action is taken. 

Alternatively, the deal is submitted to the 
trader for authorization, in which case the workflow 
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moves to state 104 , "Pending Trader Authorization". In 
this state, the trader may authorize or reject the 
deal. If the deal is rejected, the workflow returns to 
state 102, at which point the client may update the 
5 deal in progress and resubmit for authorization, or may 
delete the deal. 

As stated above, in state 104, the deal may 
be authorized by the trader, in which case the workflow 
moves to state 106, "Pending Middle Office Processing", 
jg 10 In certain cases, which are explained in further detail 

fg below, the deals must be additionally authorized by AAA 

and before being sent to the middle office for 

-3 

f7 processing. In this case, the deal is sent to state 

~ 105, "Pending AAA authorization". Upon AAA 

15 authorization, the workflow moves to state 106 for 
middle office processing. Otherwise, if AAA rejects 
the deal, the workflow returns to state 104, at which 
point the deal may be updated or rejected back to the 
client . 

20 In state 106, the middle office may authorize 

the deal, and depending upon the deal action type, 
either sends it to the back office, in which case the 
workflow moves to state 107 "Active Deals in Back 
Office", or to the inactive deals, in which case the 
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workflow moves to state 108 "Inactive Deals". Upon 
deal authorization, the client is notified of the same. 

Alternatively, the middle office may reject 
the deal back to the trader, in which case the workflow 
5 returns to state 104, or to the AAA authorizer, in 
which case the workflow returns to state 105. In the 
former case, the trader may update the deal and 
^ resubmit it to the middle office (to state 106), or may 

Ci instead send the rejected deal back to the client (to 

jr 10 state 102). In the latter case, the AAA authorizer can 

VI 

-a 

00 update the deal and resubmit it to the middle office 

^ (to state 106), or may instead send the rejected deal 

f; back to the trader (to state 104), which is handled by 

*==j the trader as described above. 

15 In addition, the middle office may propose 

that the deal be canceled, in which case the workflow 
returns to state 104. The trader may then cancel the 
deal and notify the client, or may reject the proposed 
cancellation, in which case the workflow returns to 
20 state 106. 

Deals are characterized by an action type 
(listed with its associated abbreviation), including 
but not limited to: 

New deals: ND; 
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Change (aka Correct/Edit): CH; 

Termination - Full: FT; 

Termination - Partial: PT; 

Assignment - Full Only: FA; 
5 Cancellation: CA; 

Option Exercise: CX; or 

Option Expiry: OX. 
Further, deal in progress may be saved or deleted, new 
deals may be rejected, deals may mature, and proposals 
10 may be rejected. 

If the deal action is a full termination, a 
cancellation, and option exercise or an option expiry, 
all of which represent of inactive deals, the middle 
office authorizes the deal to be sent to state 108. 
15 Otherwise, if the deal is a new or corrected deal, or 
involves a partial termination or an assignment, all of 
which represent active deals, the deal is sent to the 
back office for further processing (in accordance with 
the required action), state 107. In addition, the deal 
2 0 may mature via the payment system of the back office, 
in which case it becomes inactive and the workflow 
moves to state 108. 

The back office may make certain proposals to 
the deal to the trader, as follows: changes (edits); 
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full terminations; partial terminations; assignments; 
cancellations; option exercise; or option expiry. 
These proposals move the workflow back to the trader in 
state 104. The trader in turn may update the deal to 
5 reflect the proposal, in which case the workflow 
proceeds from state 104 as described above (i.e, to 
states 102, 105 or 106), or the trader may reject the 
proposal back to the back office, state 107. 

In addition, the small circles represent 

10 points (l)-(8) at which external publication may occur 
be the printing of "drop copies," described in more 
detail below. 

In the system of the present invention, each 
state has a group of users responsible for processing 

15 the ticket while it is in that state. When processing 
in a given state has been completed, a user may move 
the ticket onto the desktops of the users responsible 
for processing in the next state, which is called 
herein the "State Transition Process". Each time a 

20 ticket is submitted for authorization or is authorized, 
a dialog box may be displayed. Within this dialog box, 
the user may specify which users, or group of users, 
should be prompted to process the ticket next. The 
dialog box preferably has a default, pre-selected user 



or group of users who are responsible for processing in 
the next state. However, it is possible to include 
more users to the workflow through this dialog box, but 
the ability to exclude users is preferably restricted* 

As a ticket moves from a Deal in Progress 
from user to user through the workflow, it appears in 
the user inbox of the user(s) responsible for 
processing it* The user inbox is preferably 
represented by an on-screen indicator which provides 
notification of the number of deals awaiting processing 
by that user or group of users . The user may be 
notified of the arrival of new deals for processing. 
By selecting this indicator with the mouse, a user can 
view a list of unprocessed deals. The time each item 
was received in the user inbox may also be displayed. 
The user can drill down directly from the list into the 
deal awaiting processing. 

In addition to routing tickets for workflow 
purposes, system users may also send informational 
messages to other system users. When moving tickets 
from one state to another, the same dialog box used to 
move the ticket to the next user in the workflow also 
allows distribution of an FYI Message to other users 
not directly in the workflow. The user receiving the 
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FYI Message can read the message and drill down to the 
ticket attached to it in Read-only Mode. FYI Messages 
may also be sent directly at any point in the system, 
with no deal attachment. The user is preferably 
5 notified of the arrival of new FYI Messages. Each user 
typically has an on-screen indicator that provides 
notification of the number of unread FYI messages in 
the user's queue. By selecting this indicator with the 
mouse, a user can view a list of all messages. The 

10 time each message was received may also be indicated. 
Read items are preferably differentiated from unread 
items, and the user can delete any item. 

Each user can display a dialog box with a 
summary of items in the user inbox and the FYI message 

15 queue. 

Ownership of a Deal in Progress may be handed 
off from user to user before being submitted for trader 
authorization, which is called herein a "Deal in 
Progress Transfer". A dialog box is preferably 
20 displayed allowing the first user to specify which user 
will own and process the ticket next. While the Deal 
in Progress Transfer appears to be similar to the State 
Transition Process, the movement of a Deal in Progress 
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from the queue of one user to another is a lateral 
transfer with no state change. 

Before an "AAA" Deal in Progress becomes an 
authorized deal, it must be approved by an AAA business 
5 manager. This approval is initially obtained during a 
phone call between the trading desk and the AAA 
business manager. The marketer or trader preparing the 
ticket typically records the name of the person 
granting AAA approval on the Deal in Progress. 

10 A Deal in Progress enters the system workflow 

by being submitted to a trader for authorization. (See 
Fig. 7) This function can be performed by a marketer 
submitting a Deal in Progress to a trader, or by a 
trader submitting a Deal in Progress to another trader. 

15 Upon submission, the state of the Deal in Progress will 
change to Deal Pending Trader Authorization 104, and 
the trader will be prompted to authorize it. 

During Trader Authorization, a Deal Pending 
Trader Authorization becomes an authorized deal for 

20 processing by Middle and Back Office users. In the 
case where there is no marketer in the workflow, a 
trader may authorize a deal directly from the Deal in 
Progress state 102 to the Middle Office Processing 
state 106. Preferably, all required fields are checked 



for population and all fields are validated. If these 
criteria are met, the Deal in Progress ID is 
relinquished, and a unique, permanent ID is assigned to 
the authorized deal. 

A deal requiring AAA authorization must be 
authorized by an AAA business manager before moving to 
the Pending Middle Office Processing state 106 (an 
initial authorization by the AAA business manager was 
previously done while the Deal in Progress is created, 
as described above). The trader authorizing an AAA 
trade is advised that the trade is being submitted for 
AAA authorization, and the state of the deal changes to 
Pending AAA Authorization 105. AAA system users 
subsequently authorize the deal to the Pending Middle 
Office Processing state 106. 

Middle office authorization occurs when the 
deal has been captured on all relevant risk management 
and payment systems. (See Fig. 8) The deal then 
enters its final active state, Active Deals in Back 
Office 107. 

After trader authorization, users may propose 
changes to a deal by entering Proposed Edit Mode. 
Certain aspects of the on-screen appearance of the 
deal, such as the desktop background color, preferably 
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change to indicate that the deal is in Proposed Edit 
Mode, System fields that are editable in at least one 
state then become editable. An optional free-format 
comment field may also be made available to users to 
5 capture an explanation of the proposed edit. 

Once proposed edits have been attached, a 
deal is typically re-submitted for trader authorization 
in state 104. Usually, the trader who initially 
authorized the deal becomes responsible for accepting 

10 or rejecting proposed edits. 

Once submitted, proposed edits preferably 
appear in the user inbox of the trader who originally 
authorized the deal. A proposed edit symbol appears 
next to deals with attached proposed edits to 

15 differentiate them from other Deals Pending Trader 

Authorization. The trader can select the item with the 
mouse and view a summary of proposed edits, which 
include both the original and proposed values of the 
fields being edited. The user proposing the edit, the 

20 time the edit was proposed, and the comment explaining 
the edit may also be displayed. 

A trader may apply or reject all proposed 
edits, or selectively apply or reject edits to specific 
fields. If at least one proposed edit is applied, the 
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amended ticket is sent through the workflow. If all of 
the proposed edits are rejected, the ticket is not re- 
sent through the workflow. In either case, the user 
who submitted the proposed edit is typically advised of 
5 which edits were applied or rejected. 



proposed edit process, except that it is a separate 
menu item, and that users propose cancellation of the 
deal in its entirety, rather than modification of 
10 selected fields. A cancellation ticket is sent through 
the workflow. 



very similarly to proposed edits in system. The 
process may be initiated and authorized at the trader 

15 level, or initiated downstream and submitted for trader 
authorization. In cases of termination or assignment, 
the user is typically prompted for termination or 
assignment fee information, legal effective date, and 
economic effective date. 

2 0 For full termination, the termination ticket 

is sent through the workflow. For partial termination, 
the user is preferably prompted for the terminated 
notional amount. The original ticket with amended 
notional amount is then sent through the workflow. For 



The cancellation process works like the 



Terminations and assignments are processed 
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a full assignment, the user is preferably prompted to 
enter a new Party A or Party B. The original ticket 
with amended Party A or Party B is then sent through 
the workflow. In the case of partial assignment, the 
5 user is preferably prompted for the assigned notional 
amount and the new Party A or Party B for the assigned 
amount, A new Deal in Progress for the assigned amount 
may then be authorized by the trader and sent through 
the workflow. The original ticket with amended 

10 notional amount is then sent through the workflow. 

An audit trail of all changes made to an 
authorized deal may be maintained. Each time a 
proposed edit to a deal is applied by a trader, a 
static copy of the historical version of the deal is 

15 stored on the database. The user can display a dialog 
box summarizing the changes. The user can also select 
any change with the mouse and display a complete 
historical version of the deal. The user can further 
display a dialog box summarizing the deal's current 

20 state and an audit trail of its state transition 

history. The state transition history records state 
transitions, the name of the user initiating the state 
transition, and the time it was initiated (see Fig. 
10). The confirmation status of the deal may also be 
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displayed, including whether the confirmation has been 
sent, or signed and returned. This feature thus 
permits a client to access the state transition history 
of a deal . 

5 

FILE PROCESSING 

This section describes a preferred method of 
processing filed in the system of the present 
invention. Files may be Custom Templates, Deals in 

10 Progress, or authorized deals. 

New files in the system may be created as 
Deals in Progress or Custom Templates. A Deal in 
Progress is created when a System Template, a Custom 
Template, or an authorized deal is saved by the user as 

15 a Deal in Progress. A Custom Template is created when 
a System Template, a Custom Template, or an authorized 
deal is saved by the user as a Custom Template. This 
method of Creating New Files allows a user to open an 
existing file for the sole purpose of saving it as a 

20 new file owned by that user. 

Users may browse files across all states in 
the system, may filter on approximately 50 fields (see 
Fig. 9), and may specify which fields are included in 
the result set. In addition to being able to drill 
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down to the deal level directly from the file browser, 
the user can save favorite queries, and print or 
download result sets to a spreadsheet. In addition, 
the user can quickly re-access the four most recently 
5 used files in system. 

System files may be opened by users in Write 
Mode, or in Read-only Mode. Whether a file may be 
opened, and it what mode it may be opened, is dependent 
on File Edit Permissions and File Write Lock. When a 

10 deal is open in Write Mode all system fields that a 
user has Edit Permissions for are editable. When a 
user attempts to open a file in Write Mode, the system 
checks whether that user already has another deal open 
for writing, or whether a second user has the same deal 

15 open for writing. If the first user already has a deal 
open for writing, the user is advised that two files 
cannot be simultaneously open for writing. The user 
then has the option of either closing the first file, 
or of opening the second file in Read-only Mode. If a 
. 20 second user has the same file open for writing, the 

first user is informed of the time the file was write 
locked, and the identity of the second user. The first 
user has the option of opening the second file in Read- 
only Mode. 
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File edit permissions are determined by deal 
state and user profile. When a user attempts to open a 
file in Write Mode, the system checks whether that user 
has permission to edit that file based on the functions 
5 associated with the group to which the user belongs. 
The system preferably checks whether the file is 
editable based on the state in which the deal is. In 
either case, the user is advised that the file is not 
editable, and the reason it is not editable. The user 

10 then has the option of opening the second file in Read- 
only Mode. When a deal is open in Read-only Mode, no 
system fields are editable. 

Custom Templates and Deals in Progress are 
treated as the property of the user that creates them. 

15 Ownership of a Custom Template implies the ability to 
view it, to edit it, or to change viewing permissions, 
while ownership of a Deal in Progress implies the 
ability to view it, to edit it, or to enter it into the 
workflow. Files are generally viewable by all users 

20 through the deal browser, with the exception of Custom 
Templates and Deals in Progress. Since each user may 
be maintaining a number of Custom Templates and Deals 
in Progress, viewing will initially be limited to the 
file owner. Users can transfer Custom Template 
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ownership to another user. This function is typically 
invoked if first user no longer wanted to maintain or 
control access to the Custom Template. Users also can 
share Custom Templates by opening up view permssions to 
other users. A user with view permissions would not be 
allowed to edit a Custom Template, but would be able to 
save and become the owner of a new version of it. Deal 
in Progress ownership and view permissions are changed 
in the system workflow as a Deal in Progress Transfer, 
described above. 

Files that are open for writing may be 
"closed clean". If the file was open in Read-only 
Mode, the file will be dismissed from the screen. If 
the file was open for writing, the user will be 
prompted to save changes . 

PAYMENT AND RISK MANAGEMENT VIEWS 

This section describes a preferred payment 
and risk management views of the system of the present 
2 0 invention. The Payment (Customer) View of the deal is 
the way the deal is captured in system, and the way the 
deal is preferably referenced in documentation between 
the investment bank house and the counterparty. The 
Risk Management View of the deal is the way the legs of 
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a deal must be broken up on the investment bank's risk 
management and payment systems . The system captures 
both views, as follows. 

The payment view of a deal is created as deal 
5 information is captured. This is the default view in 
the system. Initially, the Risk Management View and 
the Payment View are the same. This is because in the 
case of generic deals, the payment legs of a deal may 
be acceptable as risk management legs. The Middle 

10 Office reviews all payment legs to verify that they can 
be booked in risk management systems. If a payment leg 
cannot be used as a risk management leg, however, the 
Middle Office has to create risk management legs in 
System. Middle Office users are then required to 

15 specify which risk management system on which each risk 
management leg is booked. When a deal is opened in 
Write Mode or in Read-only Mode, the Payment View will 
be presented. The user can switch to the Risk 
Management View by selecting a menu item. When the 

20 Risk Management View is being displayed it is 
preferably prominently indicated on the screen. 

ADMINISTRATIVE FUNCTION 
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This section describes the administrative 
functions preferably implemented in the system of the 
present invention. These administrative functions 
ensure that system security is enforced, that deal 
5 information is captured correctly, that new product 
types are identified and accounted for in the template 
structure, and that tickets move smoothly through the 

_ workflow. 

o 

rJJ User preferences are user level 

Ir? 10 administration functions that allow customization of 

S3 default settings, workflows, and filter criteria. 

s The User Profile contains information about each user's 

f; System administrative privileges and group membership. 

^ This information is viewable at the user level, but 

15 editable only by someone with User Profile 
Administration privileges. Middle Office 
administrative users are preferably responsible for 
creating, updating, and deleting system User Profiles. 
Middle Office administrative users are also preferably 
20 responsible for maintaining system User Groups. This 

includes defining system privileges for each User Group 
and assigning individual users to User Groups. 

Middle office administrative users are also 
preferably responsible for creating, updating, and 
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deleting system System Templates , and monitoring the 
comment field of all deals for information that cannot 
be captured on an existing Template. If the data could 
have been captured on an existing Template, the user 
generates a proposed edit; otherwise, the user either 
adds an existing field to a System Template, or defines 
a new field and adds it to the System Template. By 
adding a new field, an existing System template may be 
modified, or a new System template may be created. The 
ticket may then be re-submitted for Trader 
Authorization as a proposed edit as described above, 
and the comment field is empty. 

To ensure that tickets are processed in a 
timely manner, middle office administrative users 
preferably monitor the number of deals in the workflow 
in each state. Using the file browser, they can view 
deals across all states. 

ADDITIONAL FUNCTIONS 

This section describes certain additional 
functions which may be implemented to enhance the 
capturing and processing of deals, as described above. 
First, system users can print files open in Write Mode 
or Read-only Mode, and can select and deselect deal 
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components to be printed through a dialog box. In 
addition, users can define the output format of the 
printed ticket. All print selections are viewable 
through a print preview function. Further , the system 
5 can generate "drop copies" of tickets at specified 
times, such as state transitions. 

If a file is open for writing, the user may 
be allowed to discard any changes made to the file 
since it was opened by invoking a "revert to last saved 
10 version of a file" function. A dialog, box asks the 

user to confirm the action and advises that any changes 
will be lost. If confirmed, the file is then closed 
without saving changes and the last saved version is 
re-opened. 

15 If a file is open for writing, the user may 

be allowed to return all fields to their defaulting 
values by invoking a "revert to field defaults" 
function. A dialog box asks the user to confirm the 
action and advises that any changes to fields with 

20 defaulting values will be lost. 

If a file is open for writing, the user may 
be allowed to clear all data, including defaulting 
values, from fields on the file by invoking a "clearing 
all fields" function. A dialog box will ask the user 
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to confirm the action and advise that any data in 
fields will be lost. 

Generic text edit functions, such as those 
typically found in Microsoft applications, are made 
available to the user. For example, the user may cut, 
copy, and paste text items. 

Based on captured trade data, a graphical 
flow diagram of all legs is generated for viewing and 
printing. 

While the present invention has been 
described in detail with reference to the preferred 
embodiments thereof, many modifications and variations 
thereof will be readily apparent to those skilled in 
the art. Accordingly, the scope of the invention is 
not to be limited by the details of the preferred 
embodiments described above, but only by the terms of 
the appended claims. 



